Elements of Programming Languages

class Value case class NumV(n: Int) extends Value case class BoolV(b: Boolean) extends Value (Technically, we could encode booleans as integers, but in general we will want to separate out the kinds of values.) Booleans and Conditionals Types Extending the interpreter // helpers def add(v1: Value, v2: Value): Value = (v1,v2) match { case (NumV(v1), NumV(v2)) => NumV (v1 + v2) } def mult(v1: Value, v2: Value): Value = ... def eval(e: Expr): Value = e match { // Arithmetic case Num(n) => NumV(n) case Plus(e1,e2) => add(eval(e1),eval(e2)) case Times(e1,e2) => mult(eval(e1),eval(e2)) ... } Booleans and Conditionals Types Extending the interpreter // helper def eq(v1: Value, v2: Value): Value = (v1,v2) match { case (NumV(n1), NumV(n2)) => BoolV(n1 == n2) case (BoolV(b1), BoolV(b2)) => BoolV(b1 == b2) } def eval(e: Expr): Value = e match { ... case Bool(b) => BoolV(b) case Eq(e1,e2) => eq (eval(e1), eval(e2)) case IfThenElse(e,e1,e2) => eval(e) match { case BoolV(true) => eval(e1) case BoolV(false) => eval(e2) } } Booleans and Conditionals Types Aside: Other Boolean operations We can add Boolean and, or and not operations as follows: e ::= · · · | e1 ∧ e2 | e1 ∨ e2 | ¬(e) with evaluation rules: e ⇓ v e1 ⇓ v1 e2 ⇓ v2 e1 ∧ e2 ⇓ v1 ∧B v2 e1 ⇓ v1 e2 ⇓ v2 e1 ∨ e2 ⇓ v1 ∨B v2 where again, ∧B and ∨B are the mathematical “and” and “or” operations These are definable in LIf , so we will leave them out to avoid clutter. Booleans and Conditionals Types Aside: Shortcut operations Many languages (e.g. C, Java) offer shortcut versions of “and” and “or”: e ::= · · · | e1 && e2 | e1 || e2 e1 && e2 stops early if e1 is false (since e2’s value then doesn’t matter). e1 || e2 stops early if e1 is true (since e2’s value then doesn’t matter). We can model their semantics using rules like this: e1 ⇓ false e1 && e2 ⇓ false e1 ⇓ true e2 ⇓ v2 e1 && e2 ⇓ v2 e1 ⇓ true e1 || e2 ⇓ true e1 ⇓ false e2 ⇓ v2 e1 || e2 ⇓ v2 Booleans and Conditionals Types What else can we do? We can also do strange things like this: e1 = 1 + (2 == 3) Or this: e2 = if 1 then 2 else 3 What should these expressions evaluate to? There is no v such that e1 ⇓ v or e2 ⇓ v ! the Totality property for LArith fails, for LIf ! If we try to run the interpreter: we just get an error Booleans and Conditionals Types One answer: Conversions In some languages (notably C, Java), there are built-in conversion rules For example, “if an integer is needed and a boolean is available, convert true to 1 and false to 0” Likewise, “if a boolean is needed and an integer is available, convert 0 to false and other values to true” LISP family languages have a similar convention: if we need a Boolean value, nil stands for “false” and any other value is treated as “true” Conversion rules are convenient but can make programs less predictable We will avoid them for now, but consider principled ways of providing this convenience later on. Booleans and Conditionals Types Another answer: Types Should programs like: 1 + (2 == 3) if 1 then 2 else 3 even be allowed? Idea: use a type system to define a subset of “well-formed” programs Well-formed means (at least) that at run time: arguments to arithmetic operations (and equality tests) should be numeric values arguments to conditional tests should be Boolean values Booleans and Conditionals Types Typing rules, informally: arithmetic Consider an expression e If e = n, then e has type “integer” If e = e1 + e2, then e1 and e2 must have type “integer”. If so, e has type “integer” also, else error. If e = e1 × e2, then e1 and e2 must have type “integer”. If so, e has type “integer” also, else error. Booleans and Conditionals Types Typing rules, informally: booleans, equality and conditionals Consider an expression e If e = true or false, then e has type “boolean” If e = e1 == e2, then e1 and e2 must have the same type. If so, e has type “boolean”, else error. If e = if e0 then e1 else e2, then e0 must have type “boolean”, and e1 and e2 must have the same type. If so, then e has the same type as e1 and e2, else error. Note 1: Equality arguments have the same (unknown) type. Note 2: Conditional branches have the same (unknown) type. This type determines the type of the whole conditional expression. Booleans and Conditionals Types Concise notation for typing rules We can define the possible types using a BNF grammar, as follows: Type 3 τ ::= int | bool For now, we will consider only two possible types, “integer” (int) and “boolean” (bool). We can also use rules to describe the types of expressions: Definition (Typing judgment ` e : τ) We use the notation ` e : τ to say that e is a well-formed term of type τ (or “e has type τ”). Booleans and Conditionals Types Typing rules, more formally: arithmetic If e = n, then e has type “integer” If e = e1 + e2, then e1 and e2 must have type “integer”. If so, e has type “integer” also, else error. If e = e1 × e2, then e1 and e2 must have type “integer”. If so, e has type “integer” also, else error. ` e : τ for LArith n ∈ N ` n : int ` e1 : int ` e2 : int ` e1 + e2 : int ` e1 : int ` e2 : int ` e1 × e2 : int Booleans and Conditionals Types Typing rules, more formally: equality and conditionals ` e : τ for LIf b ∈ B ` b : bool ` e1 : τ ` e2 : τ ` e1 == e2 : bool ` e : bool ` e1 : τ ` e2 : τ ` if e then e1 else e2 : τ We indicate that the types of subexpressions of == must be equal by using the same τ Similarly, we indicate that the result of a conditional has the same type as the two branches using the same τ for all three Booleans and Conditionals Types Typing judgments: examples ` 1 : int ` 2 : int ` 1 + 2 : int ` 4 : int ` 1 + 2 == 4 : bool .. ` 1 + 2 == 4 : bool ` 42 : int ` 17 : int ` if 1 + 2 == 4 then 42 else 17 : int .. ` if 1 + 2 == 4 then 42 else 17 : int ` 100 : int ` (if 1 + 2 == 4 then 42 else 17) + 100 : int Booleans and Conditionals Types Typing judgments: non-examples But we also want some things not to typecheck: ` 1 == true : τ ` if 42 then e1 else e2 : τ These judgments do not hold for any e1, e2, τ . Booleans and Conditionals Types Fundamental property of typing The point of the typing judgment is to ensure soundness: if an expression is well-typed, then it evaluates “correctly” That is, evaluation is well-behaved on well-typed programs. Theorem (Type soundness for LIf) If ` e : τ then e ⇓ v and ` v : τ . For a language like LIf , soundness is fairly easy to prove by induction on expressions. We’ll present soundness for more realistic languages in detail later. Booleans and Conditionals Types Static vs. dynamic typing Some languages proudly advertise that they are “static” or “dynamic” Static typing: not all expressions are well-formed; some sensible programs are not allowed types can be used to catch errors, improve performance Dynamic typing: all expressions are well-formed; any program can be run type errors arise dynamically; higher overhead for tagging and checking These are rarely-realized extremes: most “statically” typed languages handle some errors dynamically In contrast, any “dynamically” typed language can be thought of as a statically typed one with just one type. Booleans and Conditionals Types